Gate 品牌戰略重磅升級
啓用全球域名 Gate.com,全新 Logo 同步上線!
以更簡潔、高辨識度、全球通用的視覺語言,開啓從領先到引領的新徵程!
✨ 三大戰略升級:
1. 用戶至上:服務全球 2300 萬用戶,儲備金率 128.57% 穩居行業前列
2. 技術創新:率先採用零知識技術驗證儲備金安全性
3. 全球合規:Gate 是全球少數具備多地區合法運營能力的加密平台之一
正如 12 周年盛典宣言,我們正朝“超級獨角獸交易所”進化。
全新品牌標識不僅是 Gate 大門的開啓,更是通向加密未來的信任橋梁!
https://www.gate.io/announcements/article/45055
#GateCom # #GateNewLogo#
如何去除中繼
MEV-Boost是當前以太坊中提取MEV的側車協議,嚴重依賴於稱為中繼的中心化參與者。我們提出了一種替代架構,允許構建者和提議者之間進行直接的、密碼學上私密的通信。這種架構基於一種新穎的非交互式“靜默”門限加密形式,可以使用驗證者現有的BLS密鑰對。
本質上,我們通過門限加密區塊提議,將其發送給一部分參與者,從而藉助證明委員會實現隱私和數據可用性。他們的證明形成解密密鑰;一旦達到所需的門限,區塊就可以被解密。
我們的構建方案解決了構建者和提議者之間的隱私問題,但單獨並不能保證區塊的有效性。它可以與其他機制結合,以完全複製中繼提供的功能,包括隱私和區塊有效性。例如,可以使用受信執行環境(TEE)證明或零知識(ZK)證明,或通過加密經濟機制為構建者提供擔保。
通過消除對中繼提供構建者隱私和確保區塊有效性的需求,我們旨在減少延遲,提高以太坊的去中心化和抗審查能力。
MEV-Boost與中繼的作用
MEV-Boost是一個側車協議,充當區塊構建者和提議者之間的中介。中繼的主要作用是提供兩個保障:
然而,對中繼的依賴引入了顯著的中心化。大約90%的以太坊區塊通過僅幾家中繼傳遞。這帶來了幾個風險:
TEE-Boost
替代中繼的主要提案之一是“TEE-Boost”,它依賴於受信執行環境(TEEs)。需要注意的是,TEEs並不是我們方案的核心;使用TEE-Boost作為我們旨在解決的問題的教學示例是很有幫助的。
具體來說,TEE-Boost要求構建者使用TEEs創建證明,向提議者展示其出價的誠實性和區塊的有效性,而無需向提議者透露實際的區塊內容。提議者可以在普通硬件上檢查這些證明,而無需自己運行TEEs。
然而,TEE-Boost存在數據可用性問題:構建者只與提議者共享TEE證明和區塊頭,而不共享實際的區塊內容[1],並且可能選擇在提議者簽署頭部後不釋放區塊內容(例如,如果市場條件發生不利變化)。解決這一數據可用性問題的建議方法包括:
TEE-保管:TEE-保管在提議者簽署之前從構建者那裡獲取區塊,並在看到簽名頭後釋放該區塊。
數據可用性層:構建者將加密的區塊負載發佈到數據可用性(DA)層。
這兩種方法都有缺點。TEE-保管解決方案複製了類似於現有中繼的中心化延遲動態[2]。如果使用外部DA層,則會引入額外的協議假設,並承受該外部協議的延遲動態(這些動態也可能不利)。
從理論上講,如果提議者也可以訪問TEEs,構建者可以將其區塊加密到提議者運行的TEE中。提議者的TEE只有在簽署後才會解密該區塊。然而,我們認為TEE-Boost沒有考慮這種設計,因為這將要求提議者(驗證者)運行TEEs。我們希望驗證者能夠在普通硬件上運行。↩
如果提議者自己將TEE-保管作為與其驗證者節點共同部署的側車運行,則可以避免延遲動
態。然而,我們同樣不希望使驗證者運行TEEs。↩
門限密碼學以實現構建者隱私
我們提出了一個優雅的解決方案來應對TEE-Boost的數據可用性問題:對驗證委員會進行門限加密。具體來說,構建者將區塊門限加密到該時隙的指定比例的驗證委員會。一旦收集到足夠的認證,區塊就可以解密並可用。
核心啟用技術是無聲門限加密。這種密碼學技術允許進行門限加密,而無需先前構建所需的交互式分佈式密鑰生成(DKG)設置階段。相反,聯合公鑰是根據驗證者已有的BLS公鑰和一些“提示”(稍後討論)確定性計算得出的。
這實現了構建者和驗證者之間的直接單跳通信,具有密碼學隱私性。驗證者不需要自己運行TEEs或管理任何新的密鑰材料。
機制:
構建者構建一個區塊並將其加密到驗證委員會。
構建者構建一個TEE證明,向驗證委員會證明三個方面:出價是誠實的,區塊是有效的,並且加密是正確的。
構建者將門限加密的區塊和TEE證明(包括出價值)傳達給提議者。[3]
提議者對獲勝構建者的加密區塊進行簽名,並將該提議傳播給驗證者集。
一旦指定比例(例如n/2或2n/3)的驗證委員會對區塊進行認證,它就會被解密。
解密後的區塊將正常進行最終確認。
注意事項
表現
無聲門限加密的性能特徵相當有利。在這裡,n是我們希望支持的委員會的最大規模,t是解密的門限。
加密和部分解密的時間都是常量時間。使用簡單實現,加密耗時小於7毫秒,並且可以並行化。部分解密耗時小於1毫秒。
密文大小比明文大768字節,這是一個常量附加因素(對於任何n和t)。
部分解密的聚合(即解密)取決於委員會的大小。當n=1024時,簡單實現的耗時小於200毫秒。我們預計,當n=128(每個時隙的認證委員會的大小)時,這一時間將減少10倍,並且實現可以進一步優化。
重要的是,加密時間是與中繼延遲進行比較的關鍵性能指標。這是構建者在區塊生成的“關鍵路徑”中必須計算的內容。這個時間低於現有中繼的區塊處理延遲,並避免了多跳通信。
數據發佈
無聲門限加密並不是完全免費的。它確實需要一個共同的參考字符串,形式為:(g, gτ, gτ², …, gτⁿ⁻ᵗ),類似於用於KZG多項式承諾方案的內容。
此外,每個具有形式為g⁽ˢᵏ⁾的BLS公鑰的驗證者發佈一組我們稱之為“提示”的群元素:(g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ)。這些提示僅在聚合公鑰和解密密文時需要。加密只使用常量大小的聚合公鑰。
截至撰寫本文時,大約有100萬個驗證者。如果我們設置n=128和t=n/2,每個驗證者需要發佈大約3KB的提示。因此,存儲所有驗證者的提示需要3GB的空間。
隨著MaxEB的激活,這一要求可能會顯著降低,MaxEB允許控制超過32 ETH的驗證者在同一密鑰對下持有更大的餘額(而不是將其分散到多個32 ETH的存款中)。將實現的驗證者集的減少還有待討論。我們可能會降至約1GB。
最後,根據以太坊共識架構的未來變化(例如,驗證者集規模的進一步減少或替代最終性流水線),必須存儲的提示大小可能會進一步減少。
活力
以太坊希望在不利網絡條件下仍然保持在線。該方案的一個問題是,由於指定比例的委員會處於離線狀態,可能會出現無法解密的區塊。
一個解決方案是允許構建者決定可接受的委員會比例(t)用於解密。隱私(解包和MEV竊取的可能性)與委員會閾值在線的可能性之間存在權衡。對構建者而言,使他們的區塊被包含在鏈中,而不是被分叉,是最大化收入的,所以他們應該找到一個優化的閾值設置。[4]
此外,使用該加密方案應為自願選擇。在不利網絡條件下,如果沒有任何可接受規模的委員會能夠持續在線,提案者和構建者可以回退到使用中繼、自建或根據不利環境的性質選擇的其他機制。
具體而言,構建者的區塊被分叉出去的期望價值是負的(他們從中沒有收入),而被解包的期望價值是非常負的。如果讓構建者選擇t在[0, 128]之間,他們應該自然而然地激勵選擇一個足夠高的t,以降低解包的風險並提高被滿足的概率(至少t名委員會成員在線)。在正常網絡條件下,一些區塊可能會被分叉出去,但我們注意到這已經發生在時間博弈中,而鏈的活躍性仍然是可接受的。↩
不可用的塊
另外,委員會可能在線,但構建者可能能夠製造一種情況,使得區塊在解密時無法解密或無效(例如,使用欺詐性證明)。
從協議的角度來看,將這些區塊分叉出去是可以的。更廣泛的驗證者集簡單地無法對此類區塊或任何引用它們的區塊進行證明。處理這種錯誤的最佳方法可能是使共識客戶端意識到這種可能性,並能夠優雅地失敗。對此需要進一步研究。
市場結構
獲勝的構建者在達到閾值之前知道區塊的內容,這可能在後續時段中造成不公平的優勢。然而,證明委員會應該在下一個時段結束之前採取行動,而區塊價值的大部分集中在時段結束時,因此這種優勢的影響應儘可能地減小。
純粹的密碼學證明
從長遠來看,可能有機會用零知識證明(ZK證明)替代TEE證明。目前,ZK證明的速度太慢,但在密碼學、軟件和專用硬件(ASICs)方面的進展可能最終會使ZK證明生成在必要的延遲限制內變得可行。值得注意的是,伴隨區塊的ZK證明已經是以太坊長期路線圖的核心部分。
採用
根據當前的驗證者集規模和增長率,這種方案可能不值得在L1上發佈所需的數據量。然而,以太坊已經計劃通過MaxEB顯著減少驗證者數量。
最好的方法可能是在MaxEB之前或之後進行升級,使共識客戶端能夠意識到加密區塊語義的可能性,並鼓勵驗證者發佈提示。例如,在MaxEB之後,可以要求新加入的驗證者發佈提示,而舊有的驗證者可以獲得升級的激勵。
一旦足夠比例的驗證者集採用這一機制,構建者就會開始使用它,以確保有足夠的委員會規模(即,兼顧隱私和解密的可能性)。
如果我們的方法在延遲方面確實優於多跳轉發,市場應該會自發採用它,而無需協議強制使用或規定特定的參數化設置。
基本原理
中繼是以太坊最重要的中心化來源之一,導致尋租機會並扭曲協議的地理去中心化。我們需要移除中繼,並認為這是一個相對優雅的解決方案。它需要對共識層進行更改,但驗證者無需提供新的硬件或密鑰材料。
缺點是,這是對共識層的複雜更改,而這種機制(如果如建議的那樣選擇性採用)可能會被市場接受,也可能不會。然而,許多潛在的MEV管道變化也面臨類似的採納和收益最優化問題(例如,包括列表)。並且,未來可能會有其他用例依賴於驗證者集擁有閾值加密基礎設施。
聲明: